The present application relates generally to an improved data processing apparatus and method and more specifically to mechanisms for providing a generic declaration of bindings between events and event handlers that operates regardless of the underlying runtime structure in which events are occurring.
Nearly any modern architecture for building a graphical user interface (GUI) includes an event subsystem. The event subsystem is responsible for managing the events that occur, i.e. are “fired,” either by the GUI runtime environment or due to user interaction with the GUI. An event may be a key press, mouse click, a GUI component receiving focus, the text in a text field becoming invalid due to a user entering additional text, or the like.
Most GUI frameworks also allow GUI developers to bind an action to be performed to a particular type of event that is fired by a specific event target, i.e. the control that is rendered as a result of the declaration of a GUI component. The specification of the action that is to be performed upon the firing of an event is called the event handler and the act of binding the event handler to an event is often implemented as code that registers or adds a listener to the event subsystem. The listener, in object-oriented programming, is an object that receives the event and processes it appropriately. In order for a listener to receive events, the listener must be registered as an event listener on the event source object and it must implement an appropriate interface.
FIG. 1 illustrates the relationship between an event source and an event listener using a JavaScript example. As shown in FIG. 1, an event source 110, e.g., a GUI component or element, has a corresponding registered event listener 120, which may be registered with the event source 110 by a client or other object. The event listener 120 operates as an event listener for a particular type of event that may be fired by the event source 110. When an event occurs, the runtime environment 130 first determines the event source 110 and type of the event. If an event listener 120 is registered with the event source for this type of event, an event object 140 is generated. Then, for each registered event listener 120 for this type of event, the runtime environment 130 invokes an appropriate event handling method of the event listener 120 and passes the event object 140 to the event handling method as a parameter.
In the HyperText Markup Language (HTML), events are bound to certain elements via a predefined set of attributes on the elements that declare the creation of the GUI component. Here, the event is given by an attribute, the event target is the element to which the attribute is attached, or more precisely, the control that is rendered as the result of the declaration of the element, and the event handler is usually a block of JavaScript code that is performed when the event is fired. For more information regarding events and event handling in HTML, reference is made to the HTML 4.01 specification available at the WorldWide Web (W3) Consortium website.
The following is an example of Java Swing™ code (an Application Programming Interface for providing a graphical user interface for Java programs) for implementing an event handler that itself implements an event listener:
public class ExampleClass implements ActionListener { ...   JButton button = new JButton(“Example Button!”);   button.addActionListener(this); ...   public void actionPerformed(ActionEvent e) { numClicks++;   label.setText(labelPrefix + numClicks);   }}
With this example in mind, it should be noted that the event listener has three important portions. First, the event listener has a declaration of the event handler class and specifies whether the event handler class implements a listener interface or extends a class that implements a listener interface. In this example, the declaration is “public class ExampleClass implements ActionListener {”. Second, the event handler has a portion of code, referred to herein as the registration code, that registers an instance of the event handler class as a listener of one or more GUI components or elements so that the event handle may be registered as an event listener. In this example, the registration code is “button.addActionListener(this)”. Third, the event handler has a portion of code, referred to herein as the implementation code, that implements the methods in the listener interface. In this example, the implementation code is “public void actionPerformed(ActionEvent e) {numClicks++; label.setText(labelPrefix+numClicks);}”.
There are three main problems with the approach of registering event handlers and listeners with event sources in HTML in the manner generally known in the prior art. First, the types of events that can be observed are limited by HTML itself. If new events are to be observed, the HTML itself must be restated. Second, the event handler must take a specific form, usually script code in a specified file on the client computing device or server computing device, or within the document itself. Third, HTML presupposes a particular type of runtime structure. Namely, HTML presupposes a document object model (DOM) rendered inside a web browser or similar user agent.
Another example of declarative markup language for specifying renderable structures is XForms (a description of which may also be found at the W3 Consortium website) which uses the Extensible Markup Language (XML) Events specification to declare its event bindings. In XML Events, no assumption is made about the event types that can be observed except that the event type must be a legal XML name. In addition, the specification of an event handler is more generic since its value must only satisfy the criterion that it is a Uniform Resource Identifier (URI). Nonetheless, this language is still limited because the event handler cannot be specified as a Java class or executable on the client computer. That is, the language itself simply does not have syntax for this type of specification. Moreover, the XML Events specification still suffers in that it is tied to a particular runtime structure and presupposes a DOM as understood by the DOM Level 2 specification.